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DETAILED ACTION 

Response to Amendment 

1 . This office action is in response to the Applicant's After Non-Final Amendment filed on 
March 5, 2008. Applicant amended claims 1, 3, 6-7, 9-10, 14, 16, and 20, canceled 
claims 21-23, and added claims 24-26. Claims 1-20 and 24-26 are presented for further 
consideration and examination. 

Double Patenting 

2. The nonstatutory double patenting rejection is based on a judicially created doctrine 
grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. A nonstatutory 
obviousness-type double patenting rejection is appropriate where the conflicting claims 
are not identical, but at least one examined application claim is not patentably distinct 
from the reference claim(s) because the examined application claim is either anticipated 
by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 
F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 
USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 
1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 
F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 
644 (CCPA 1969). 
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A timely filed terminal disclaimer in compliance with 37 CFR 1 .321 (c) or 1 .321 (d) may be 
used to overcome an actual or provisional rejection based on a nonstatutory double 
patenting ground provided the conflicting application or patent either is shown to be 
commonly owned with this application, or claims an invention made as a result of 
activities undertaken within the scope of a joint research agreement. 
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal 
disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 
3.73(b). 

3. Claims 1, 16, 20, and 24-26 are rejected on the ground of nonstatutory obviousness-type 
double patenting as being unpatentable over claims 1-2, 15-16, and 22 of U.S. Patent 
No. US007269696B2. Although the conflicting claims are not identical, they are not 
patentably distinct from each other because they are both directed to create and 
maintain a plurality of virtual servers, such as virtual filers (vfilers). 

Claim Rejections - 35 USC §102 

4. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1 ) an application for patent, published under section 1 22(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351 (a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 
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5. Claims 1-3. 6. 12-17. 20. and 24-26 are rejected under 35 U.S.C. 1 02(e) as being 
anticipated by Becker-Szendy et al. (US007243089B2). 



6. With regard to claims 1, 16, 20, and 24-26 , Becker-Szendy discloses, 

• a plurality of network resources adapted to process received block-based 
protocol data access requests; and (Becker-Szendy, col.1 , line 10 - col.20, line 
48) 

Becker-Szendy discloses, "The present invention satisfies this need, and 
presents a system, a computer program product, and an associated method 
(collectively referred to herein as "the system" or "the present system") and a 
service for federating a local file system into a distributed file system (FS), while 
preserving local access to the existing data in the local file system. The present 
system may provide indirect access to local file systems using protocols such as, 
for example, storage tank protocols, object-based storage protocols, block-based 
protocols, etc. The server-based design of the present system allows systems to 
migrate their data and share the management of data. The data is federated, or 
made available to various clients by making it on-line to each client. The present 
system may be used with any file system protocol that supports migration, 
consistency and multi-host federation" (Becker-Szendy, col.2, lines 49-64). 
Becker-Szendy discloses, "For purposes of illustration, the use of the present 
system is described in terms of a storage tank system. Storage tank is a 
distributed file system built on a storage area network. Data may be stored either 
in block storage devices or object storage servers. Unlike most file systems, 
meta-data and data are stored separately in the storage tank system. The server 
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manages meta-data comprising the location of the blocks of each file/object on 
shared storage. Object storage servers enable the creation of self-managed, 
heterogeneous, shared storage by offering a higher-level storage abstraction in 
the form of objects" (Becker-Szendy, col.2, line 65 - col. 3, line 8). Becker- 
Szendy discloses, "The virtual object storage server 250 and the virtual metadata 
server 245 run against the local file system 210. The storage tank client 235 
sends metadata requests to the virtual metadata server 245" (Becker-Szendy, 
col. 10, lines 38-41). Hence, Becker-Szendy teaches of the system (e.g., storage 
tank system, distributed file system built on a storage area network) providing 
indirect access (i.e., Applicant's adapted to process) to local file systems (i.e., 
Applicant's plurality of network resources) using protocols such as storage tank 
protocols, object-based storage protocols, block-based protocols, etc. (i.e., 
Applicant's one or more block-based protocols) by having the storage tank client 
sending metadata requests (i.e., Applicant's data access request) and the virtual 
metadata server responding to the requests appropriately. 
• one or more virtual servers each comprising a logical partitioning of the network 
resources to establish an instance of a multi-protocol server configured to service 
the block-based data access requests by converting the blocked-based protocol 
requests to appropriate file system data requests. (Becker-Szendy, col.1, line 10 
-col.20, line 48) 

Becker-Szendy discloses, "An embodiment of the federation design of the 
present system relies on object storage servers. The present system creates a 
virtual storage tank server and a virtual object storage server on top of the local 
file system to make the local file system appear as both a storage tank node and 
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an object based storage server to a storage tank system. Data accesses go 
through the virtual object storage server, and not through the virtual storage tank 
server. It should be clear that the storage tank server provides metadata 
information to the client, who then accesses the data directly from the object 
based storage server. Storage tank uses the object storage server interface to 
access the local file system data. After the local file system is exposed through 
the storage tank file system, data may be left on-line and stored in the local file 
system or migrated to a new storage device through storage tank tools. While the 
present system is described in terms of storage tank, it is not limited to storage 
tank and may be expanded to other file systems" (Becker-Szendy, col. 3, lines 50- 
67). Hence, Becker-Szendy teaches of the virtual storage tank server and the 
virtual object storage server (i.e., Applicant's one or more vfilers) on top of (i.e., 
Applicant's comprising a logical partitioning) the local file systems (i.e., 
Applicant's network resources). Becker-Szendy teaches of the virtual object 
storage server (i.e., Applicant's multi-protocol server) allowing (i.e., Applicant's 
configured to service) data accesses (i.e., Applicant's data access requests) 
indirectly to the local file systems (i.e., Applicant's network resources) using (in 
response to) protocols such as block-based protocol. Becker-Szendy discloses, 
"In the local file system 210, objects are accessed not by their object ID number 
but by their file names. System 205 provides a mapping from file name to object 
ID number, and a reverse mapping from object ID number back to the file name. 
This mapping is unambiguous and stable. System 205 implements the mapping 
by having the virtual metadata server 245 and the virtual object storage server 
250 use the object ID database 255 that is shared between them. The object ID 
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database 255 maps the file name to object ID number, and reverse maps the 
object ID number to a file name" (Becker-Szendy, col.11, lines 1-11). Hence, 
Becker-Szendy teaches of the system 205, which includes the virtual metadata 
server 245 and the virtual object storage server 250 (i.e., Applicant's virtual 
servers), implementing the mapping (i.e., Applicant's converting) of the client's 
data access requests so that they can be understood by local file system 210 
(i.e., Applicant's to appropriate file system data requests). 



7. With regard to claim 2 , Becker-Szendy discloses, 

• wherein the network resources comprise network interfaces assigned to one or 
more network address resources. (Becker-Szendy, col.1, line 10 - col.20, line 
48) 

Becker-Szendy discloses, "Storage tank uses the object storage server interface 
to access the local file system data. After the local file system is exposed through 
the storage tank file system, data may be left on-line and stored in the local file 
system or migrated to a new storage device through storage tank tools. While the 
present system is described in terms of storage tank, it is not limited to storage 
tank and may be expanded to other file systems" (Becker-Szendy, col. 3, lines 50- 
67). 



8. With regard to claims 3 and 1 7 , Becker-Szendy discloses, 

• further comprising storage media configured to store information as units of 
storage resources, the units of storage resources allocated among each of the 
vfilers. (Becker-Szendy, col.1, line 10 - col.20, line 48) 
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Becker-Szendy discloses, "The term "disk" references the actual storage device, 
whether it is an individual disk (attached via DAS or SAN), or a logical unit on a 
disk array. Disks that are used by the storage tank system 300 are attached via a 
SAN. The SAN may be comprised of, for example, fiber channel, iSCSI, etc. A 
disk that partitions its storage space into many objects is an object store device, 
also referenced as an object based store. The traditional disk is called a block 
disk. The storage tank system 300 can use both traditional block disks, as well as 
object store devices to store the contents of files" (Becker-Szendy, col. 3, lines 
50-67). Hence, Beck-Szendy teaches of the actual storage device (i.e., 
Applicant's storage media) partitioned (i.e., Applicant's configured to store 
information) its storage space into many object store devices (i.e., Applicant's 
units of storage resources). Becker-Szendy teaches the storage tank system, 
which includes the virtual storage tank server and the virtual object storage 
server (i.e., Applicant's vfilers), using (i.e., Applicant's allocated) both traditional 
block disks and object store devices (i.e., Applicant's units of storage resources). 



9. With regard to claim 6 , Becker-Szendy discloses, 

• further comprising an operating system having a file system resource adapted to 
perform a boundary check to verify that a request is allowed to access certain 
units of the storage resources on the storage media, each vfiler allowed shared 
access to the file system and further adapted to create virtual disks within the 
units of storage resources and wherein each of the virtual disks associated with 
one or more of the vfilers. (Becker-Szendy, col.1, line 10 - col.20, line 48) 
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Becker-Szendy discloses, "Data consistency is maintained in that existing 
applications may modify data in the file system during migration or federation. 
During federation, other computer systems (or hosts) may modify the data in the 
file system if access control information allows them to do so. All changes in the 
file system are seen consistently on all hosts. Minimal downtime is required to 
install the present system and reconfigure the existing applications to 
communicate with the present system" (Becker-Szendy, col.3, lines 20-28). 



10. With regard to claims 12-13 , Becker-Szendy discloses, 

• wherein the block-based protocol comprises iSCSI. (Becker-Szendy, col.1 , line 
10-col.20, line 48) 

Becker-Szendy discloses, "The term "disk" references the actual storage device, 
whether it is an individual disk (attached via DAS or SAN), or a logical unit on a 
disk array. Disks that are used by the storage tank system 300 are attached via a 
SAN. The SAN may be comprised of, for example, fiber channel, iSCSI, etc. A 
disk that partitions its storage space into many objects is an object store device, 
also referenced as an object based store. The traditional disk is called a block 
disk. The storage tank system 300 can use both traditional block disks, as well as 
object store devices to store the contents of files" (Becker-Szendy, col.3, lines 
50-67). 

• wherein the block-based protocol comprises FCP. (Becker-Szendy, col.1 , line 1 0 
-col.20, line 48) 

Becker-Szendy discloses, "The term "disk" references the actual storage device, 
whether it is an individual disk (attached via DAS or SAN), or a logical unit on a 
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disk array. Disks that are used by the storage tank system 300 are attached via a 
SAN. The SAN may be comprised of, for example, fiber channel, iSCSI, etc. A 
disk that partitions its storage space into many objects is an object store device, 
also referenced as an object based store. The traditional disk is called a block 
disk. The storage tank system 300 can use both traditional block disks, as well as 
object store devices to store the contents of files" (Becker-Szendy, col. 3, lines 
50-67). 



1 1 . With regard to claims 14-15 , Becker-Szendy discloses, 

• further comprising a context data structure provided to each vfiler, a context data 
structure including information pertaining to a security domain of a vfiler and 
enforces controlled access to the allocated and shared resources. (Becker- 
Szendy, col.1, line 10-col.20, line 48) 

Becker-Szendy discloses, "File data is the bytes that are actually stored in a file. 
Metadata is all the rest of the information stored in a file system. Metadata 
comprises the directory tree and the attributes of objects such as files and 
directories. The directory tree is a set of names that are arranged in directories, 
forming a tree structure. Typical attributes comprise time stamps (i.e., time 
created, time last modified, time last read) and security related attributes (i.e., the 
identity of the owner of the object and a description of what the owner or other 
parties may do to the object). In addition, with object based storage, it is possible 
to have some of the metadata stored on the object based storage. For example, 
object based storage manages the block mapping internally, off-loading this role 
from the file system" (Becker-Szendy, col.7, lines 41-54). 
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• wherein the multi-protocol server is further adapted to process data access 
requests in response to one or more file-level protocols. Becker-Szendy 
discloses, "The present invention satisfies this need, and presents a system, a 
computer program product, and an associated method (collectively referred to 
herein as "the system" or "the present system") and a service for federating a 
local file system into a distributed file system (FS), while preserving local access 
to the existing data in the local file system. The present system may provide 
indirect access to local file systems using protocols such as, for example, storage 
tank protocols, object-based storage protocols, block-based protocols, etc. The 
server-based design of the present system allows systems to migrate their data 
and share the management of data. The data is federated, or made available to 
various clients by making it on-line to each client. The present system may be 
used with any file system protocol that supports migration, consistency and multi- 
host federation" (Becker-Szendy, col.2, lines 49-64). 



Claim Rejections - 35 USC § 103 

12. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 



13. 



Claims 4-5 and 18-19 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Becker-Szendy et al. (US007243089B2) and in view of Mane et al. 
(US20050050107A1). 
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14. With regard to claims 4-5 and 18-19 , Becker-Szendy discloses, 
See claims 3 and 1 7 rejection as detailed above. 
However, Becker-Szendy does not explicitly disclose, 

• wherein the units of storage resources comprise volumes. 

• wherein the units of storage resources comprise qtrees. 
Mane teaches, 

• wherein the units of storage resources comprise volumes. (Mane, para. 1-53) 
Mane discloses, "The processor 25 includes a number of program layers, 
including a network interface 26 for coupling to the data network, a file system 
layer 27 for organizing data into a hierarchical file system of files and directories, 
a volume layer 28 for organizing the data into logical volumes of data blocks, and 
a Small Computer System Interface (SCSI) driver 29 for linking the volume layer 
28 to the disk storage 24" (Mane, para.25). Hence, Mane teaches of logical 
volumes of data blocks (i.e., Applicant's volumes) as units of storage resources. 

• wherein the units of storage resources comprise qtrees (Mane, para. 1-53) 
Mane discloses, "In accordance with another aspect, the invention provides a 
method of maintaining quotas for storage resources used by a file server for 
storing files in selected directory trees of a file system. The file server has a tree 
quota database of usage values of the storage resources and limit values for the 
storage resources for the selected directory trees of the file system" (Mane, 
para.6). Hence, Mane teaches of a tree quota database (i.e., Applicant's qtree) 
as a unit of storage resources. 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time of 
the invention was made to combine the teachings of Mane with the teachings of 
Becker-Szendy to "[provide] a method of maintaining quotas for storage resources 
used by a file server for storing files in selected directory trees of a file system" 
(Mane, para. 5). Mane discloses, "A preferred way of preventing the renaming of a 
file from causing an undesired nesting of quota trees is to prevent the renaming of a 
file from causing a file to be moved into, out of, or between quota trees. In the 
preferred implementation, the quota are treated as if they were separate file systems 
by returning a cross-device error if the renaming of a file would otherwise cause a file 
to be moved into, out of, or between quota trees" (Mane, para.48). Becker-Szendy 
discloses, "What is therefore needed is a system, a service, a computer program 
product, and an associated method for federating an old system into a new system, 
and optionally migrating data from an old system to a new system. This method 
should operate seamlessly and efficiently with minimum disruption to existing 
applications running on the system. Further, this method should ensure data 
consistency for existing applications while making the data available for migration in 
a federated system. The need for such a solution has heretofore remained 
unsatisfied" (Becker-Szendy, col.2, lines 35-44). 

15. Claims 7-11 are rejected under 35 U.S.C. 103(a) as being unpatentable over Becker- 
Szendy et al. (US007243089B2) and in view of George et al. (US007010663B2). 

16. With regard to claim 7 , Becker-Szendy discloses, 

See claim 6 rejection as detailed above. 
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However, Becker-Szendy does not explicitly disclose, 

• wherein the operating system further comprises a user interface having a 
command set adapted to operate on virtual disks, and wherein the command set 
executes within a context of a vfiler. 

George teaches, 

• wherein the operating system further comprises a user interface having a 
command set adapted to operate on virtual disks, and wherein the command set 
executes within a context of a vfiler. (George, col.1 , line 8 - col. 14, line 58) 
George discloses, "Referring now to FIG. 2, the data storage device 120 of FIG. 
1 is shown that provides for managing a plurality of virtual LUNs over one or 
more existing volumes of storage within the storage device 120, in accordance 
with one embodiment of the present invention. The data storage device 120 
comprises two interfaces for receiving and sending command line interface (CLI) 
instructions and Input/Output (I/O) data. The interfaces include a CLI interface 
and a hypertext transfer protocol (HTTP) interface" (George, col. 5, lines 33-41 ). 
Hence, George teaches of two interfaces (i.e., Applicant's user interface) for 
receiving and sending instructions (i.e., Applicant's having a command set) for 
managing (i.e., Applicant's adapted to operate on) a plurality of virtual LUNs (i.e., 
Applicant's virtual disks) over one or more existing volumes of storage via the 
virtualization layer (i.e., Applicant's within a context of a vfiler). 

Therefore, it would have been obvious to one of ordinary skill in the art at the time of 
the invention was made to combine the teachings of George with the teachings of 
Becker-Szendy to provide a method for "partitioning the existing volumes into a 
plurality of slices. Each of the plurality of slices is then mapped to the plurality of 
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virtual LUNs. Furthermore, each of the plurality of virtual LUNs is masked to each of 
the plurality of host applications to provide access control. Moreover, the plurality of 
host applications are transparently interfaced with the existing volumes via a 
visualization software layer that interfaces with and preserves the originally 
configured internal intelligence (e.g., internal operating code) that accesses the 
plurality of volumes" (George, col.2, lines 39-49). Georges discloses, "Embodiments 
of the present invention relate to the field of data storage systems. More particularly, 
embodiments of the present invention relate generally to the expansion of an existing 
data storage system into a plurality of virtual data storage systems" (George, col.1 , 
lines 9-13). Becker-Szendy discloses, "What is therefore needed is a system, a 
service, a computer program product, and an associated method for federating an 
old system into a new system, and optionally migrating data from an old system to a 
new system. This method should operate seamlessly and efficiently with minimum 
disruption to existing applications running on the system. Further, this method should 
ensure data consistency for existing applications while making the data available for 
migration in a federated system. The need for such a solution has heretofore 
remained unsatisfied" (Becker-Szendy, col.2, lines 35-44). 



17. With regard to claims 8-9 , Becker-Szendy and George disclose, 

• wherein the user interfaces comprises a command line interface (CLI) adapted to 
support the command set. (Becker-Szendy, col.1, line 10 - col.20, line 48; 
George, col.1, line 8 - col. 14, line 58) 

George discloses, "Referring now to FIG. 2, the data storage device 120 of FIG. 
1 is shown that provides for managing a plurality of virtual LUNs over one or 
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more existing volumes of storage within the storage device 120, in accordance 
with one embodiment of the present invention. The data storage device 120 
comprises two interfaces for receiving and sending command line interface (CLI) 
instructions and Input/Output (I/O) data. The interfaces include a CLI interface 
and a hypertext transfer protocol (HTTP) interface" (George, col. 5, lines 33-41 ). 
• wherein the CLI comprises a lun command adapted to perform operations to a 
virtual disk associated with the context of the vfiler. (Becker-Szendy, col.1, line 
10 - col.20, line 48; George, col.1, line 8 - col. 14, line 58) 
George discloses, "Typically, the CLI interface provides access by a user (e.g., 
system administrator) to configure, update, and/or modify the data storage device 
120, such as, creating or removing virtual LUNs, and expanding or reducing the 
size of virtual LUNs, etc. In FIG. 2, the CLI interface is provided through port task 
215 that functions essentially for properly routing the CLI instructions through 
storage device 120. In another embodiment, the HTTP interface, through port 
task 210, also allows access by a user to configure the storage device 120. In 
addition, the HTTP interface, through port task 210, provides for an avenue for 
access by other users and host applications to the data storage device 120, as 
will be discussed" (George, col.5, lines 42-54). 



18. With regard to claims 10-1 1 Becker-Szendy and George disclose, 

• wherein the lun command creates a logical unit number on a file system 
associated with the server, the logical unit number being associated with the 
context of the vfiler. (Becker-Szendy, col.1, line 10 - col.20, line 48; George, 
col.1, line 8 -col. 14, line 58) 
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George discloses, "This disclosure describes a method and apparatus for slicing 
one or more volumes of storage into a plurality of virtual LUNs, thereby 
increasing the number of accessible LUNs within a data storage network. Also, 
another embodiment of the present invention discloses a method and system for 
increasing the number of host applications that can access and use a particular 
volume of storage" (George, col.4, lines 11-17). 
• wherein the CLI comprises an igroup command that generates a set of file 
system primitive for binding an initiator group to one or more initiator addresses 
and wherein the initiator group is associated with the context of the virtual server. 
(Becker-Szendy, col.1, line 10 - col.20, line 48; George, col.1, line 8 - col. 14, line 
58) 



Response to Arguments 

19. Applicant's arguments with respect to claims 1 and 24 have been considered but they 
are not persuasive. 



20. With regard to claims 1 and 24 , the Applicant points out that: 

• Applicant respectfully submits that Becker-Szendy fails to teach or disclose 
Applicant' s claimed novel: "one or more virtual servers each comprising a logical 
partitioning of the network resources to establish an instance of a multi-protocol 
server configured to service the block-based data access requests by converting 
the block-based protocol requests to appropriate file system data requests. " 
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• More particularly, Applicant respectfully submits that Becker-Szendy fails to 
teach or disclose Applicant's claimed novel: "converting the block-based protocol 
requests to appropriate file system data requests". 

• Applicant respectfully notes that Becker-Szendy does not, in text cited by the 
Examiner, mention or teach Applicant's claimed novel converting the block-based 
protocol requests to appropriate file system data requests. Moreover, Applicant 
respectfully notes that the term "block-based protocol" only appears twice in the 
Becker-Szendy patent. In both instances, Becker-Szendy does not disclose 
converting the block-based protocol request to file system data requests. 

• Applicant respectfully submits that for the same reasons asserted under the 102 
analysis, Becker-Szendy fails to teach or suggest Applicant's claimed novel 
converting the received block-based data access request to a file system data 
access request. 

However, the Examiner finds that the Applicant's arguments are not persuasive 
because Becker-Szendy discloses, "An embodiment of the federation design of the 
present system relies on object storage servers. The present system creates a virtual 
storage tank server and a virtual object storage server on top of the local file system 
to make the local file system appear as both a storage tank node and an object 
based storage server to a storage tank system. Data accesses go through the virtual 
object storage server, and not through the virtual storage tank server. It should be 
clear that the storage tank server provides metadata information to the client, who 
then accesses the data directly from the object based storage server. Storage tank 
uses the object storage server interface to access the local file system data. After the 
local file system is exposed through the storage tank file system, data may be left on- 
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line and stored in the local file system or migrated to a new storage device through 
storage tank tools. While the present system is described in terms of storage tank, it 
is not limited to storage tank and may be expanded to other file systems" (Becker- 
Szendy, col. 3, lines 50-67). Hence, Becker-Szendy teaches of the virtual storage 
tank server and the virtual object storage server (i.e., Applicant's one or more vfilers) 
on top of (i.e., Applicant's comprising a logical partitioning) the local file systems (i.e., 
Applicant's network resources). Becker-Szendy teaches of the virtual object storage 
server (i.e., Applicant's multi-protocol server) allowing (i.e., Applicant's configured to 
service) data accesses (i.e., Applicant's data access requests) indirectly to the local 
file systems (i.e., Applicant's network resources) using (in response to) protocols 
such as block-based protocol. Becker-Szendy discloses, "In the local file system 
210, objects are accessed not by their object ID number but by their file names. 
System 205 provides a mapping from file name to object ID number, and a reverse 
mapping from object ID number back to the file name. This mapping is unambiguous 
and stable. System 205 implements the mapping by having the virtual metadata 
server 245 and the virtual object storage server 250 use the object ID database 255 
that is shared between them. The object ID database 255 maps the file name to 
object ID number, and reverse maps the object ID number to a file name" (Becker- 
Szendy, col.11, lines 1-11). Hence, Becker-Szendy teaches of the system 205, 
which includes the virtual metadata server 245 and the virtual object storage server 
250 (i.e., Applicant's virtual servers), implementing the mapping (i.e., Applicant's 
converting) of the client's data access requests so that they can be understood by 
local file system 210 (i.e., Applicant's to appropriate file system data requests). 
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Conclusion 

21 . THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the 
extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the 
advisory action. In no event, however, will the statutory period for reply expire later than 
SIX MONTHS from the date of this final action. 

22. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Thomas Duong whose telephone number is 571/272-391 1 . The 
examiner can normally be reached on M-F 7:30AM - 4:00PM. If attempts to reach the 
examiner by telephone are unsuccessful, the examiner's supervisor, Jason D. Cardone 
can be reached on 571/272-3933. The fax phone numbers for the organization where 
this application or proceeding is assigned are 571/273-8300 for regular communications 
and 571/273-8300 for After Final communications. 

Thomas Duong (AU2145) 
June 11, 2008 



/Jason D Cardone/ 
Supervisory Patent Examiner, Art Unit 2145 



